Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ien / ien-126 < prev next >

Wrap

Text File | 1988-12-01 | 32.1 KB | 710 lines

IEN 126 Danny Cohen U S C / I S I November 1979 SUMMARY OF THE ARPA/ETHERNET COMMUNITY MEETING On Thursday, October 18th, 1979, a meeting was held at Xerox-PARC to discuss the support of ETHERNET based communication in the ARPA sponsored internetwork environment (INE). The following participated in the meeting: - CMU (Bob Sproull) - ISI (Danny Cohen) - MIT-LCS (Dave Clark) - Stanford University (Forest Baskett, John Seamas, Bill Nowicki) - University of Rochester (Ed Burke) - Xerox-PARC (Ed Taft, Mike Schroeder, Ron Crane, John Shoch) It turned out that Caltech, which is another ARPA site, already has four ALTOs and an Ethernet. They were not represented in this meeting, and probably should be made part of this ARPA/Ethernet community. The group reached an agreement about the way to support both IP- and PUP-based communication in such a way that the richness of both worlds is preserved. This can be encapsulated in the following: when in conflict, use IP as a transport (hence, lower level) protocol for PUP. A detailed discussion of this issue follows, in (A) below. Page 2 One cannot over-emphasize that this effort is NOT aimed to provide an automatic translation/conversion between the IP-based and the PUP-based software, but to support coexistence and mutual support of both communication regimes. Providing that conversion service is a noble goal, but unfortunately is too complicated to be considered as a part of this effort because it involves complicated technical issues like addresses in a non-uniform set of internetwork environments. However, even though no automatic direct conversion is provided between these regimes, a certain degree of compatibility and inter-operability exists due to hosts which "talk" both "languages". This capability is provided by the ability to transfer files back and forth between the IP- and the PUP-worlds, to forward mail, to cascade TELNET connections, and the like. In addition, the existence of PUP-based Xerox products (like Dovers, ALTOs and Penguins) in the ARPA community requires, to a certain degree, the ability to support PUP communication among sites which are already a part of the IP-internet, without requiring them also to participate in the PUP-internet. Basically the entire group agreed to work toward communication compatibility and effort sharing. Since there is a great deal of commonality of both hardware and software requirements among the sites, we expect to be able to share both hardware and software efforts by exchanging and copying interface designs, exchange of software, and the like. According to the proposed agreement, the IP-world and the PUP-world can coexist in such a way that ARPA maintains complete control of the former and Xerox-PARC of the latter. This control is the assignment of network-IDs, updating of routing-tables, name-servers, etc. Ethernets may participate in the PUP-world, or serve just as private local access systems, which are not part of any internetworking environment. In either case, the Ethernets may be totally transparent to the outside, while supporting traffic between IP-hosts, and no symmetry is required between the communicating sites, i.e., a site without an Ethernet does not have to be aware that the other site uses an Ethernet for its local access. The following sections are: (A) A discussion of the proposed relation between the protocols, (B) The hardware/software components which will probably be developed at individual sites and made available to other participants. This is a tentative list and should not be viewed as a firm commitment, and (C) The list of the participants, addresses, etc. Page 3 (A) IP/PUP Communication THE PROBLEM Support communication between Ethernet-based systems at different sites, by using either the IP- or the PUP-based protocols, over the ARPA sponsored InterNetwork Environment (INE). This is NOT intended to provide inter-operability of these protocols, only their co-existence. APPROACH Both the IP and PUP assume that they are the sole level-1 internetwork protocols. Since the ARPA-sponsored INE already has many gateways which are based on IP, we chose to encapsulate PUP inside IP for traversing the INE. Note that this doesn't exclude the dual, namely IP inside PUP. This encapsulation may be performed either by hosts or by gateways. The interaction between IP and PUP is based on the ability of each to act as the transport for the other. This is a slight deviation from our previous simplistic notion of pure hierarchy of protocols which allows the drawing of nice tree structures with unique level-number to each protocol. Since both IP and PUP can be either "above" or "below" the other -- strange loops [GEB] may result. It is important not to exclude the ability of each IP-host to have its own unique IP-address, while each PUP-host has its own unique PUP-address, if so desired, without excluding the ability to have both. Page 4 DISCUSSION Sites which use mainly IP probably are better off by performing this encapsulation by the hosts, and have a E-IP-A ("pure-IP") gateway. Here "E" is the Ethernet protocol and "A" is the external transport net protocol (e.g. ARPAnet) which is used to connect this site to the INE. Let's use the notation X<Y to mean that X is a lower level protocol than the protocol Y and is used as a transport for Y, by encapsulating the Y-messages inside the X-messages. If the "<" and ">" are considered as arrows, note that they always point "down", to the lower level protocol and do not indicate direction of flow. By using this notation the above gateway may be described as E<IP>A. Again, the "arrows" do not indicate direction of flow, but indicate the encapsulation/decapsulation of messages as they flow through this gateway in either direction. According to the philosophy of IP both the "E" and the "A" are considered as "local" even though "E" is a local access system and "A" is a cross-country communication system. As a matter of fact, all networks are considered as "local-networks" by this school of thought. In such sites the role of the Ethernet here is to be a local transport (level-0) for the IP traffic. However, internal (intra-site) PUP traffic may avoid the IP entirely, which is essential if Xerox black-boxes (e.g., Dovers and Penguins) are used. Note that PUP traffic cannot leave this site unless it is encapsulated in IP by the sending hosts. We refer to such sites as type S1. Sites with only PUP based traffic may choose to implement E<PUP>IP>A ("pure-PUP") gateways. This frees the local hosts from dealing with IP. We expect that only Xerox sites may use such gateways. We refer to such sites as type S2. Note that PUP traffic cannot be communicated between S1 and S2 easily. It may be kluged but should be considered as not feasible due mainly to addressing problems. Sites which have to communicate with both S1 and S2 sites have to implement a combined IP+PUP gateways. These are the S12 type sites. The gateways used by these sites are discussed in some detail later. Page 5 MORE DISCUSSION An important notion is that even though PUP is always encapsulated in IP while traversing the INE it may be performed by either the hosts (the S1 way), or by the gateways (the S2 way). In the S1 way the IP-communication is addressed to the destination IP- host (process). However, the PUP-communication inside it, if any, is addressed to a PUP-process, using PUP-addresses. In the S2 way the PUP-communication is addressed to the PUP-process in the source-gateway which is expected to perform its own routing to the PUP-process in the gateway which is the re-entry point into the PUP-world (or the exit point from the IP-world). The end-to-end communication is addressed by its PUP-address. The S1 model treats the Ethernet as a local access scheme, while IP is the internetworking regime. The S2 model treats the IP-INE as a single transporting network, while PUP is the internetworking regime. Hence, it is not expected to support communication between S1 and S2. If we use [E(IP)] to represent an IP-message encapsulated inside an Ethernet-message then the function of the S1-gateway is to perform the following transformation: [E(IP)] <=> [A(IP)], where the direction of the transformation depends on the direction of the flow, from the Ethernet into the the ARPAnet, or vice versa. Hence, the function of the S2-gateway is [E(PUP)] <=> [A(IP(PUP))]. The S12 gateway is one which can operate in either of these modes. As a matter of fact, there is one other mode of operation which is in some use, treating the ARPAnet as a communication line (level-0) for PUP. This is done by encapsulating PUP directly in ARPAnet messages, and using link-152 to designate this traffic. Note: no IP is involved. This gateway function is represented by [E(PUP)] <=> [A(PUP)]. By the way, the [A(IP)] traffic in the ARPAnet is designated by link-155. Hence, a general gateway, which uses an Ethernet for local access, has to support the following: 1. [E(IP)] <=> [A(IP)] Encapsulation of IP-messages in ARPANEt-messages. The IP-address is that of the destination IP-process. 2. [E(PUP)] <=> [A(IP(PUP))] Encapsulation of PUP-messages inside IP-messages, encapsulated in ARPANet-messages. The PUP-address is that of the destination host, the IP-address is that of the PUP-process in the destination gateway which retrieves (performs the decapsulation) of PUP from inside IP. 3. [E(PUP)] <=> [A(PUP)]. Direct encapsulation of PUP-messages inside ARPAnet-messages. Page 6 Using the previous notations, where "arrows" indicate the direction of encapsulation/decapsulation for the two-way flow, the general IP+PUP gateway can be described by the following diagram: ********** ****** ********** * <--1-----------1--< * * * * Ether- * ******* * IP >-1,2-> ARPA- * --1,2,3--< net * * >--2--> * * net >--1,2,3-- * <-2,3-< PUP * ****** * * * * * >--3----------3--> * ********** ******* ********** John Shoch observed that diagrams like this one (with or without the arrows) may be viewed as if the lines represent messages and the boxes represent processes, or as if the boxes represent messages and the lines represent processes (encapsulation/decapsulation). MORE DETAILS and EXAMPLES Let us consider communication between host-A at site-X and host-B at site-Y, where at site-X there is an Ethernet whose PUP-address is S, and at site-Y there is an Ethernet whose PUP-address is T. Here "host" is a single process and a "site" is a set of hosts connected by a local access scheme. Even though the ARPAnet is mentioned in all the following examples, one should be able to notice that in most cases it represents any network which supports IP, i.e., for which IP-gateways are implemented. Only the LINKs mentioned below are actually ARPAnet specific. Let's examine the protocol-nestings and encapsulations for FTPs. (1) Encapsulation/decapsulation into IP, by hosts. Two case are discussed in some details, (1.1) transport of TCP-traffic, and (1.2) transport of PUP-traffic. Obviously, the FTPs of (1.1) and (1.2) differ and cannot talk directly to each other, but they can communicate indirectly via a file system, such as MAXC's. Page 7 (1.1) FTP above TCP, above IP. This is the case of IP communication, using the Ethernet and the ARPAnet as part of the IP-INE. The sender, host-A, generates an IP-message of the form [IP(TCP(FTP))], carrying the IP-address Y:B, which is encapsulated in the Ethernet protocol for accessing the gateway. Hence, upon leaving host-A, the message is [E(IP(TCP(FTP)))], with the Ethernet-address of the IP-process in the gateway, by setting the Ethernet 8-bit address to that of the Ethernet interface of gateway-X, and setting the PROTOCOL field to the value 1001-octal, meaning IP-protocol. Upon receiving this message the Ethernet-process examines the value of the PROTOCOL field and recognizes the message as an IP-message. It then hands to the IP-process the message without the Ethernet header. This is the decapsulation of the message from the Ethernet encapsulation. The IP-process finds that the IP-address of the destination is Y:B. After checking its routing-tables the IP-process finds the ARPAnet address of the first gateway along the INE-route to Y. It may happen that this is also the final one, if Y is also connected directly to the ARPAnet. Next, the IP-message is encapsulated in an ARPAnet-message, carrying the ARPAnet-address of that gateway: [A(IP(TCP(FTP)))]. Upon arriving at the gateway of site-Y the local-net header is stripped off. This local network is probably the ARPAnet, if Y is connected to it directly, but may be any other network which supports IP. The resulting IP-message is handed to the IP-process. Next, the IP-message is encapsulated again in an Ethernet-message, addressed to host-B, [E(IP(TCP(FTP)))]. Upon arriving at host-B the Ethernet header is removed, and the IP-message is recovered and handed to the IP process which hands it to the TCP process, which hands it to the FTP process. Note that for this scheme to work it is not necessary for site-Y to have the same type of local-access network (here the Ethernet) as site-X has, or any other local network. Note also that in this case the Ethernet neither at site-X nor at site-Y has to have a PUP-address, and it does not have to be considered as a part of the PUP-based internetwork environment. In summary, the function of the gateway in this case is: [E(IP(TCP(FTP)))] <=> [A(IP(TCP(FTP)))]. Page 8 (1.2) FTP above BSP above PUP, above IP. This is the case of PUP-communication, using host encapsulation of PUP- messages inside IP-messages for transport through the IP-INE. The sender, host-A, generates a PUP-message of the form [PUP(BSP(FTP))], and encapsulates it in the IP-message [IP(PUP(BSP(FTP)))] which carries the IP-address Y:B, which is encapsulated in the Ethernet protocol for accessing the gateway. Hence, upon leaving host-A, the message is [E(IP(PUP(BSP(FTP))))], with the Ethernet-address of the IP-process in the gateway, by setting the Ethernet 8-bit address to that of the Ethernet interface of gateway-X, and setting the PROTOCOL field to the value 1001-octal, meaning IP-protocol. In some sense, this Ethernet might not be managed as part of the PUP-internet, but the hosts had better have valid PUP- addresses; the destination process certainly has a PUP-address -- that's why we're sending it PUP-messages! This raises the following question: how does the FTP process in the PUP destination get the PUP-address to which it will send its response? A possible answer is that the sender had better have used a valid PUP-address, including a PUP-net number. It is important to note that in this case the end processes are still sending and receiving PUP-messages and must be located within the PUP-internet address space, despite the fact that the IP encapsulation is done in the end hosts. The INE is being treated as a single PUP transport network, and the end hosts are both on the same "network". The PUP-address within a network is only 8 bits, while an IP address within any network is 24 bits. For now, we propose that an ad-hoc mapping strategy be employed. Each IP host that implements IP(PUP) encapsulation is assigned a unique PUP host number within the IP "network". IP addresses are derived from PUP-addresses by table lookup. The table is manually maintained (by Xerox-PARC) limited to 256 entries. We expect that only a few hosts will need to communicate in this manner. Upon receiving this message the Ethernet-process in the source-gateway examines the value of the PROTOCOL field and recognizes the message as an IP-message. It then hands to the IP-process the message without the Ethernet header. This is the decapsulation of the message from the Ethernet encapsulation. The IP-process finds that the IP-address of the destination is Y:B. After checking its routing-tables the IP-process finds the ARPAnet address of the first gateway along the INE-route to Y. It may happen that this is also the final one, if Y is also connected directly to the ARPAnet. Next, the IP-message is encapsulated in an ARPAnet-message, carrying the ARPAnet-address of that gateway: [A(IP(PUP(BSP(FTP))))]. Page 9 Upon arriving at the gateway of site-Y the local-net header is stripped off. This local network is probably the ARPAnet, if Y is connected to it directly, but may be any other network which supports IP. The resulting IP-message is handed to the IP-process. Next, the IP-message is encapsulated again in an Ethernet-message, addressed to host-B, [E(IP(PUP(BSP(FTP))))]. Upon arriving at host-B the Ethernet header is removed, and the IP-message is recovered and handed to the PUP process which hands it to the BSP process, which hands it to the FTP process. Note that for this scheme to work it is not necessary for site-Y to have the same local-access network (here the Ethernet) as site-X has, or any other local network. In summary, the function of the gateway in this case is: [E(IP(PUP(BSP(FTP))))] <=> [A(IP(PUP(BSP(FTP))))]. (2) Encapsulation/decapsulation into IP, by gateways. We consider a case of FTP above BSP, above PUP. This is the case of PUP-communication, using gateway encapsulation of PUP-messages inside IP-messages for transport through the IP-INE. The sender, host-A, generates a PUP-message of the form [PUP(BSP(FTP))], carrying the PUP-address T:B, which is encapsulated in the Ethernet protocol for accessing the gateway. Hence, upon leaving host-A, the message is [E(PUP(BSP(FTP)))], with the Ethernet-address of the PUP-process in the gateway, by setting the Ethernet 8-bit address to that of the Ethernet interface of gateway-X, and setting the PROTOCOL field to the value 1000-octal, meaning PUP-protocol. Upon receiving this message the Ethernet-process examines the value of the PROTOCOL field and recognizes the message as a PUP-message. It then hands to the PUP-process the message without the Ethernet header. This is the decapsulation of the message from the Ethernet encapsulation. The PUP-process finds that the PUP-address of the destination is T:B. After checking its routing-tables the PUP-process finds the PUP-address of the gateway into PUP-network T, which is the PUP-process in the gateway-Y. Then it encapsulates the PUP-message [PUP(BSP(FTP))], inside the IP-message [IP(PUP(BSP(FTP)))]. The protocol field of this IP-message is set to the value 14-octal to designate this message as a PUP-message. Page 10 Next, this IP-message is given to the IP-process with the IP-address of the PUP-process in gateway-Y. After checking its routing-tables the IP-process finds the ARPAnet address of the first gateway along the INE-route to Y. As before, it may happen that this is also the final one, if Y is also connected directly to the ARPAnet. Next, the IP-message is encapsulated in an ARPAnet-message, carrying the ARPAnet-address of that gateway: [A(IP(PUP(BSP(FTP))))]. Upon arriving at the gateway of site-Y the local-net header is stripped off. This local network is probably the ARPAnet, if Y is connected to it directly, but may be any other network which support IP. The resulting IP-message is handed to the IP-process which recognizes the message as a PUP message (by the value 14-octal in its PROTOCOL field) and hands it to the PUP-process of this gateway. However, if the network can support process-addressing, then the IP-address of this message may be that of the PUP-process in the destination gateway. Process-addressing is like addressing the "fake-host"s in the ARPAnet, for example. In this case the PROTOCOL field of the IP-header does not have to be used to be used at all. Note that there is some possible redundancy here, the message may be both marked as a PUP-message and be addressed to the PUP-process. Hence, it is possible to use only one of these two mechanisms, either the IP-header's PROTOCOL field, or the ability to address directly processes in gateways. The PUP-process has no trouble to figure the exact Ethernet-address of the destination host, T:B. Next, the PUP-message is encapsulated again in an Ethernet-message, addressed to host-B, [E(PUP(BSP(FTP)))]. Upon arriving at host-B the Ethernet header is removed, and the PUP-message is recovered and handed to the BSP process which hands it to the FTP process. Note that for such a scheme to work it is absolutely necessary for both sites to have PUP supporting networks, like the Ethernet, for example. Note also that every gateway of the [E(PUP)] <=> [A(IP(PUP))] variety must have a PUP-address in the "IP-network" as discussed in 1.2, page 8. Furthermore, the gateways must implement the ability to broadcast PUP- messages to all PUP-hosts (or at least to all other gateways) in the "IP-network" so that PUP-routing information will propagate through that "network". In summary, the function of the gateway in this case is: [E(PUP(BSP(FTP)))] <=> [A(IP(PUP(BSP(FTP))))]. Note that in this case, unlike the previous ones, there is a difference in the level of nesting between the two sides of this expression. Why? Page 11 (3) The standard PUP-internetwork gateway, treating the Ethernet and ARPAnet as independent PUP transport networks. In this case FTP is implemented above BSP above PUP, in an ARPAnet host. This is the case of PUP-communication, using the Ethernet and the ARPAnet as part of the PUP system. The sending host, A, generates an PUP-message of the form [PUP(BSP(FTP))], carrying the PUP-address T:B, which is encapsulated in the Ethernet protocol for accessing the gateway. Hence, upon leaving host-A, the message is [E(PUP(BSP(FTP)))], with the Ethernet-address of the PUP-process in the gateway, by setting the Ethernet 8-bit address to that of the Ethernet interface of gateway-X, and setting the PROTOCOL field to the value 1000-octal, meaning PUP-protocol. Upon receiving this message the PUP-process in the gateway removes the Ethernet header (hence, decapsulates the message from the Ethernet encapsulation) and finds the PUP-address of the destination, T:B. After checking its routing tables the PUP-process finds the ARPAnet-address of the gateway into PUP-network T, which is the PUP-process in the gateway-Y, which is also directly on the ARPAnet. Then it encapsulates the PUP-message [PUP(BSP(FTP))] inside the ARPAnet- message [A(PUP(BSP(FTP)))]. The LINK field of this ARPAnet-message is set to the value 152 to designate this message as a PUP-message. Upon arriving at site-Y the message the ARPAnet-process recognizes it as a PUP-message by the value of its LINK field (152), and gives it to the PUP-process of this gateway. The PUP-process has no trouble to figure the exact Ethernet-address of the destination host, T:B. Next, the PUP-message is encapsulated again in an Ethernet-message, addressed to host-B, [E(PUP(BSP(FTP)))]. Upon arriving at host-B the Ethernet header is removed, and the PUP-message is recovered and handed to the BSP process which hands it to the FTP process. Note that both sites must have PUP gateways connected to the ARPAnet; the end hosts themselves may be anywhere in the PUP-internet. All communication in this case is pure-PUP, with no IP encapsulation anywhere. By the way, the reason for having this type of gateway is to be able to talk to MAXC via the ARPAnet. MAXC speaks only pure-PUP, not IP-encapsulated PUP, and this isn't likely to change in the near future. In summary, the function of the gateway in this case is: [E(PUP(BSP(FTP)))] <=> [A(PUP(BSP(FTP)))]. Page 12 A NOTE ABOUT LOCAL ADDRESSING This section is independent of the previous sections. One may accept the previous recommendations without accepting the recommendations of this section. It is our feeling that local access scheme in general, and Ethernets in particular, should NOT be treated as NETWORKS which are globally registered in the InterNetwork directory of Networks. For sites (1) whose local access network (e.g., the Ethernet) is NOT a registered network and does not have an Internetworkly known Network-ID, issued by Jon Postel, and (2) are on the ARPAnet, it is proposed that the 8-bit LOGICAL-ADDRESS field be used as their Ethernet-address. Since the new ARPAnet address (1822, 96-bit header) is in the same format as the IP-address, this could result in a significant simplification of the gateway implementation. Hence, the proposed IP- and ARPAnet-address format is as follows: IP: |<--Network--->|<----- understood only by that network ----->| ARPAnet: |<--Network--->| IMP |Physical host | Logical host | +--------------+--------------+--------------+---------------+ | ARPAnet='12 | IMP | INTERFACE | local address | +--------------+--------------+--------------+---------------+ 8 bits 8 bits 8 bits 8 bits (The ARPAnet format is conceptually as shown above, physically it is different, obviously) The third field identifies the IMP/HOST-interface which is used for the gateway. Traditionally it is called "physical-host", but it does not identify the host, it identifies only the interface. Obviously, the 8-bits local address cannot be sufficient for a long time, and sooner or later more bits will be needed to identify all the local destinations. Thence, source routing should be used, in the same framework of protocol nesting. It is important to recognize that this will happen, eventually, and incorporate this concept in the design of current software, even though it is not about to be implemented soon. Note that for sites which are connected to the INE this approach interacts with the "multiple-homing" problem, whose solution is beyond the scope of this note. The multiple-homing problem does not exist for sites which are connected to the INE via a single gateway, like CMU for example. Page 13 (B) Available Hardware/Software NOTE: this list is a tentative list of hardware and software components which may be made available by some sites to other members of the group. This should be treated as a tentative list, rather than a firm commitment. It is always advisable to check with each group about the status of these components before counting on them. - CMU will program a PDP11/34 to serve as an IP+PUP gateway which is capable of performing the encapsulation of PUP inside IP, hence being of type S12, being able to communicate both with type-S1 and type-S2 sites. It is expected that most of the other sites will duplicate this gateway by getting an 11/34 and importing the software from CMU. - CMU may be able to implement the IP protocol in Dovers and Penguins. PARC will help. - ISI will implement an efficient PDP10-KL/Ethernet interface. - ISI will implement a PDP11-based terminal concentrator interfaced to an Ethernet. - MIT will probably implement IP (but probably not TCP) in MESA for the ALTO. - SU will build microprocessor-based Ethernet interfaces, with the MCS-68000 (or Z-8000) and the IEEE488 bus (GPIB) for the HP3000, several HP300's and twelve IBM Series/1's. Also for a VAX system. - SU will implement a microprocessor-based terminal concentrator for the Ethernet. - SU plan to interface a PDP10-KL (SAIL) via the 11/40 console. Probably the same for a PDP-KI (SUMEX), too. - PARC will be able to supply both TENEX and TOPS-20 code for handling both raw-PUPs and byte-streams, also the higher level PUP-based protocols such as FTP, EFTP, EMPRESS, PSPOOL, etc. This does not include the level-0 handling which obviously depends on the exact hardware interface. Since none of the sites is expected to have the same Ethernet interface as MAXC has, the level-0 help is not available. Page 14 (C) List of participants CMU Bob Sproull 412-578-2621 Sproull@CMUA ISI Danny Cohen 213-822-1511 Cohen@ISIB MIT Dave Clark 617-253-6003 Clark@MIT-MULTICS Stanford Forest Baskett 415-497-1916 FB@SAIL John Seamons 415-497-3236 Admin.jks@SCORE Bill Nowicki 415-497-9437 CSD.Nowicki@SCORE Ron Crane 415-494-4298 Crane@PARC U of Rochester Ed Burke 716-275-5671 Feldman@SUMEX-AIM Xerox-PARC Ed Taft 415-494-4419 Taft@PARC Mike Schroeder 415-494-4463 Schroeder@PARC Ron Crane 415-494-4298 Crane@PARC John Shoch 415-494-4384 Shoch@PARC ======================================================================== A personal comment: The main idea of traversing the ARPA-INE with [IP(PUP)] and the division between host and gateway encapsulation was conceived during discussions with Bob Sproull, at CMU. Bob deserves the credit for getting it right, but should not be blamed for the details which I managed to mess up. The meeting summary was expanded to cover in detail several technical issues (especially addressing) which were sketched in the meeting without the details which are necessary to make it all work. Therefore, putting this note together turned out to be a bigger effort than what was expected. In addition, the note attempts to explain many issues and details in a way which is (hopefully) clear even to the internetworking-naive reader. Doing so was a substantial effort which could not have been done without the help from Jon Postel and Carl Sunshine, and a tremendous help from Ed Taft and John Shoch who pointed many issues, corrected many details and rewrote several sections. Thank you all. ======================================================================== All comments are welcome, Cheers, Danny.